Most remote procedure call (RPC) implementations have the following characteristics: exclusive connection use by the RPC request, authentication and authorization procedures performed by RPC servers, and load-balancing for non-authoritative RPC servers. Existing protocols used for RPCs include Simple Object Access Protocol (SOAP), Java Remote Method Invocation (Java RMI), and Common Object Request Broker Architecture (CORBA). However, each of these protocols suffers from one or more of the problems described below.
Regarding exclusivity of connection use by RPC requests, most RPC implementations rely on sending the entire payload constituting the RPC request or response. RPC connections therefore get saturated and cannot be used for other RPCs until all bytes of the previous payload have been read from the connection. The exclusive use of the connection makes it difficult if not impossible to prioritize subsequent RPCs over the same connection.
Regarding authentication and authorization, traditional RPC servers usually implement the authentication and authorization in order to gate requests from RPC clients. Clients initiate connections and pass on credentials to the RPC server and RPC servers rely on authentication and authorization capabilities available on its infrastructure. The tight coupling of authentication/authorization with RPC server capabilities makes it difficult to implement a system wherein the RPC server needs to run in an untrusted environment. For example, for companies acquired by an enterprise, it's conceivable for the parent enterprise to be the trust entity. And therefore, to implement a traditional RPC server running in the acquired company, one would have to partially implement authentication and authorization in the acquired company, leading to fragmentation of trust relationships between the parent and acquired company.
Regarding load balancing for non-authoritative RPC servers, given that traditional RPC servers are always destinations for a connection from RPC clients, traditional RPC servers work well with current mechanisms involving load-balancing that have a higher affinity with the server's network environment. A large number of RPC clients initiate a virtual connection with a load balancer and the load balancer determines which RPC server to connect to based on how heavily the server is loaded. However for situations when the server is non-authoritative, it's the server that initiates connections to the clients via load balanced proxies. While traditional load balancing continues to be useful for this initial connection, as RPC servers begin to get loaded, traditional load balancing schemes will cause the connections to get overused, thus making them ineffective and inefficient.